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An IRTF Primer for IETF Participants 


Abstract 


This document provides a high-level description of things for 
Internet Engineering Task Force (IETF) participants to consider when 
bringing proposals for new research groups (RGs) into the Internet 
Research Task Force (IRTF). This document emphasizes differences in 
expectations between the two organizations. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Research Task Force 


(IRTF). The IRTF publishes the results of Internet-related research 
and development activities. These results might not be suitable for 
deployment. This RFC represents the individual opinion(s) of one or 
more members of the IRSG Research Group of the Internet Research Task 
Force (IRTF). Documents approved for publication by the IRSG are not 
a candidate for any level of Internet Standard; see Section 2 of RFC 
5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7418. 


Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction and Scope 


This document provides a high-level description of things for 
Internet Engineering Task Force (IETF) participants to consider when 
bringing proposals for new research groups (RGs) into the Internet 
Research Task Force (IRTF). This document emphasizes differences in 
expectations between the two organizations. 


IRTF RG guidelines and procedures are described in BCP 8 [RFC2014], 
and this document does not change those guidelines and procedures in 
any way. 


2. The IRTF Is Not the IETF 


A number of proposals from experienced IETF participants for new IRTF 
RGs have encountered problems because the IETF participants were 
making proposals appropriate for the IETF, but not for the IRTF. 
[RFC2014] describes the origin of IRTF RGs but doesn’t provide much 
detail about the process, which is intended to be flexible and 
accommodate new types of RGs. Lacking that detail, experienced IETF 
participants fall back on what they know, assume that chartering an 
IRTF RG will be similar to chartering an IETF working group (WG), 
follow the suggestions in [RFC6771] to gather a group of interested 
parties, and then follow the suggestions in [RFC5434] to prepare for 
a successful BOF and eventually, a chartered WG. 
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Both of these documents are excellent references for proposals in the 
IETF, but their suggestions may result in a proposal that is almost 
the opposite of what the IRTF Chair is looking for in a proposal for 
an IRTF RG. The mismatches fall into some consistent categories, and 
this document lists the ones that come up repeatedly. 


The target audience of this document is IETF participants bringing 
proposals to the IRTF. 


It’s worth noting that the IRTF Chair has substantial autonomy on 
what RGs are chartered and how they reach that stage. The IRTF Chair 
at the time of writing is Lars Eggert. 


2.1. Research and Engineering 


"To me, the fundamental outcome of research is understanding, and 
the fundamental outcome of engineering is a product." - Fred Baker 


In some ways, research is about a journey, and engineering is about a 
destination. If a researcher answers a question in a way that opens 

another question, that can be success. If an engineer keeps working 

on a product without finishing it, that is usually a failure. 


Research can be open-ended, while engineering can come to a stopping 
point when the result is "good enough" -- good enough to ship. 


"If it has to work when you're finished, it wasn’t research, it 
was engineering." - attributed to Dave Clark 


2.2. Scope 


IRTF RGs have a scope large enough to interest researchers, attract 
them to the IRTF, and keep them busy doing significant work. Their 
charters are therefore usually much broader than IETF WG charters, 
and RGs often discuss different topics underneath the charter 
umbrella at different times, based on current research interests in 
the field. 


IETF WGs are chartered with a limited scope and specific 
deliverables. If deliverables and milestones are known, the proposal 
is likely too limited for the IRIF. 


2.3. Time Frames 
IRTF RGs bring researchers together to work on significant problems. 
That takes time. The effort required by a RG is likely to take at 


least three to five years, significantly longer than IETF WGs 
envision when they are chartered. 
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2.4. Alternatives 


IRTF RGs are encouraged to explore more than one alternative approach 
to the chartered problem area. There is no expectation that the RG 
will "come to consensus" on one approach. The RG may publish 
multiple competing proposals as research produces results. 


IETF WGs normally use the IETF consensus process (as described in 
[RFC7282]) to drive interoperable solutions into the market place. 
That often includes reducing the number of approaches to something 
manageable for an implementer, preferably one, whether that means 
starting with an approach the WG participants agree on, or 
considering alternatives with a view to picking one rather than 
spending significant effort on alternatives that won’t go forward. 


The IRTF, as an organization, may also charter multiple RGs with 
somewhat overlapping areas of interest, which the IETF tries very 
hard to avoid. 


2.5. Process 


All IRTF participants have the obligation to disclose IPR and 
otherwise follow the IRTF’s IPR policies, which closely mirror the 
TETF’s IPR policies; in all other aspects, IRTF RG operation is much 
less constrained than IETF WG operation. 


Each IRTF RG is permitted (and encouraged) to agree on a way of 
working together that best supports the specific needs of the group. 
This freedom allows IRTF RGs to bypass fundamental IETF ways of 
working, such as the need to reach at least rough consensus, which 
IRTF RGs need not do. Therefore, the mode of operation of IRTF RGs 
can also change over time, for example, perhaps becoming more like 
IETF WG operation as the research the group has been progressing 
matures. 


2.6. Charters 


The purpose of charters in the IRTF is to broadly sketch the field of 
research that a group is interested in pursuing and to serve as an 
advertisement to other researchers who may be wondering if the group 
is the right place to participate. 


IETF WG charters tend to be very narrow. They are intended to 
constrain the work that the working group will be doing, and they may 
contain considerable text about what the working group will not be 
working on. 
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2.7. Deliverables 


There is no expectation that IRTF RGs publish RFCs, although many do. 
Some IRTF research groups produce IRTF-stream RFCs, while others 
produce Internet-Drafts that form the basis of IETF-stream RFCs, and 
still others may deliver reports, white papers, academic journal 
articles, or even carry out relevant high-level discussions that 
aren’t ever published but influence other research. IRTF RGs are 
successful when they stimulate discussion, produce relevant outputs, 
and impact the research community. 


IETF WG deliverables tend to be specific protocol, deployment, and 
operational specifications, along with problem statements, use cases, 
requirements, and architectures that inform those specifications. 
Almost all IETF working groups are chartered to deliver Internet 
standards, which isn’t an option for IRTF RGs. 


2.8. Completion 


IRTF RGs may produce the outputs they expected to produce when they 
were chartered, but it also happens that researchers consider what 
they’ve learned and start work on better solutions. This can happen 
whether or not the research underway has been completed, and the 
process can continue until the RG itself decides that it is time to 
conclude or when the IRTF Chair determines that there is no more 
energy in the group to do research. 


IETF WGs will typically conclude when they meet their chartered 
milestones, allowing participants to focus on implementation and 
deployment, although the WG mailing list may remain open for a time. 


3. Now That You Know What Not to Do 


The current IRTF Chair, Lars Eggert, is fond of saying, "Just act 
like an IRTF research group for a year, and we'll see if you are 
one." 


There are many ways to "act like an IRTF research group". [RFC4440] 
contains a number of points to consider when proposing a new RG. 
Some possibilities include: 


1. Identify and recruit a critical mass of researchers who can 
review and build off each other’s work. 


2. Identify other venues that may overlap the proposed RG, and 
understand what value the proposed RG provides beyond what’s 
already underway elsewhere. 
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3. Hold a workshop to survey work that might set the stage for a RG 
on questions of interest, perhaps in concert with existing 
academic events. 


4. If the proposed RG expects to have outputs that will ultimately 
be standardized in the IETF, identify and recruit engineers who 
can review and provide feedback on intermediate results. 


But every proposed RG is different, so e-mailing the IRTF Chair to 
start the conversation is a perfectly reasonable strategy. 


4. Security Considerations 


This document provides guidance about the IRTF chartering process to 
IETF participants and has no direct Internet security implications. 
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